-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CMSP-726] switch to gha #116
Conversation
if this doesn't work, i will remove the updatinator container and re-test with the write permissions granted
although we're overriding the token later, so this might not do anything
we shouldn't need it if we're overwriting the GITHUB_TOKEN
…ure out why we're getting bad credentials again
also remove the permissions which might be why we're getting the message, too
we'll probably fail the tests but we can see if it's needed
couldn't get it to work
this should trigger only on tag creation after the tests have run
|
||
- `composer release` | ||
Rebuild [pantheon-systems/docker-updatinator](https://github.com/pantheon-systems/docker-updatinator) to deploy a new version of the tool to the automation processes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rebuild where/how? Rebuild in github? Rebuild in Quay?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe so. This was copy/pasta from the original notes.
Co-authored-by: Phil Tyler <[email protected]>
FWIW, I don't think this is a change worthy of actually creating a new tag/release, so we won't be able to test the workflow (unless we fork and run the tests on the fork), so it's possible the release pipeline side of things might need to be tweaked in the future. |
Overview
This pull request: switches the automation workflow from CircleCI to GitHub Actions
Summary
Replaces our CircleCI workflows with native GitHub Actions so we can reduce the number of secrets in use with broad permissions in different places.
Description
For https://getpantheon.atlassian.net/browse/CMSP-726, it was discovered that a GitHub secret (Personal Access Token) was being stored in Circle to perform actions on GitHub. Rather than storing secrets in Circle (which has been compromised on occasion), and to reduce the use of secrets everywhere, a better approach was suggested to use Vault to retrieve the appropriate token.
However, since there are only two workflows being handled by Circle -- a test workflow (using entirely public repositories/images) and a publish release workflow (which publishes the release to GitHub) -- there is no specific reason to use CircleCI over native GitHub actions for these things.
This PR removes the CircleCI configuration in favor of GitHub actions that perform the same steps. The test workflow runs exactly the same tests as it did on Circle, with additional steps in place to set up the environments that the tests will be run on. Previously, this was being run on the
docker-updatinator
image, but we are able to perform the same actions on the defaultubuntu-latest
GitHub image with a few modifications. The tests use the PAT of thepantheon-ci-bot
stored in Vault for the Update Toolwhoami
and PHPUnit tests to work.The tests workflow also run on tag push. When they run on tag push, if the tests pass, they create a release dispatch. The publish workflow is triggered by this release dispatch and actually publishes the release and uploads the
update-tool.phar
to the release. This is done using native GitHub actions for release creation and asset upload and eliminates the need for thecomposer release
process (which often wasn't used in practice anyway), pinning the actual release process to the (human-controlled) process of creating a tag.The README has been updated to reflect the changes in the process. While the documentation about
composer release
is left for reference purposes, it's untested with the new release process (although it probably still works? ¯_(ツ)_/¯ ) and, at any rate, involves manually updating theVERSION
file before running the script. Simply creating a tag (either in the GitHub UI or via CLI) is a much more straightforward process and should be the recommended process for creating releases.